1. Field of the Invention
The present invention relates to eXtensible Markup Language (XML) schemas, and more particularly to XML messaging schemas which contain logical model extensions and wire format specific rendering options.
2. Description of the Related Art
In recent years, use of the eXtensible Markup Language has become increasingly prevalent in business. This trend is largely attributable to the flexibility of XML as a mechanism for defining the structure and content of data. XML allows users to define schemas comprising a set of ASCII-based elements and attributes in a structural relationship to define a non-programming language specific data type (i.e. a data type that is defined without use of particular programming language). The elements and attributes defined in an XML schema may then be used as “tags” or labels in one or more XML instance documents (i.e. XML documents conforming to an XML schema and containing actual data) which may instantiate earlier defined data types. When XML instance documents are forwarded to other users or enterprises, the XML schema may be used by the recipient to “understand” the instance document. Sharing of data across divergent operating systems and platforms is thus supported.
The World Wide Web Consortium (W3C) has provided a recommendation for XML schemas, known as “XML Schema 1.0”, which has become a de facto standard in the industry. This recommendation (alternatively referred to herein as the “W3C recommendation”) is attached hereto as Appendix I. Since its original publication, various errata have been identified in the W3C recommendation. The latter document is attached hereto as Appendix II. Subsequent references to the XML Schema 1.0 recommendation or XML Schema 1.0 standard appearing hereinafter may be understood to incorporate corrections to the errata canvassed in the latter document.
There has also recently been a phenomenal increase in Business-to-Business (“B2B”) transactions in which transaction data is encoded in XML.
A problem that has been encountered in respect of B2B transactions is the use by different enterprises of different wire formats for messages. As is known in the art, a wire format describes how data is encoded “on the wire” when it is sent from one system to another. Assuming that a business enterprise has N partners, if each partner employs a different wire format, the enterprise will be required to encode/decode the same logical data into/from N different wire formats. The encoding/decoding problem becomes onerous as the number N of wire formats becomes large.
To address the above problem, message brokers have been developed. As is known in the art, a message broker is an intermediary program which converts messages from the wire format of a sender to the wire format of a receiver. The IBM® WebSphere® Business Integration Message Broker software is one example of a message broker. IBM and WebSphere are registered trademarks of the International Business Machines Corporation.
To support efficient conversion of messages from one wire format to another, some message brokers such as the WebSphere® Business Integration Message Broker utilize a message model having two components: a logical model and a physical model. The logical model, which may be an XML schema for example, describes the logical structure of a set of messages for a particular application, e.g., banking, insurance, or travel, in a platform and programming language neutral manner. The physical model defines the manner in which the messages are represented in alternative wire formats. Such a message model is described in co-pending U.S. patent application Ser. No. 10/703,037, filed Nov. 6, 2003, which is hereby incorporated by reference hereinto.
As indicated in the above referenced application, message models of the type described above can define logical model extensions which are not supported in the standard XML schema 1.0 standard.
One example of a logical model extension is a composition kind attribute which extends the standard composition types of XML schemas (choice, sequence, and all) with the enumeration “unorderedSet”. The “unorderedSet” enumeration is similar to “sequence” (which requires all elements of a message to appear in sequence) except that elements within the set may occur in any order.
In another example of a logical model extension, a content kind attribute which comprises three enumerations representing alternative types of constraints of a message's elements that may be applicable to a message received on the wire can be defined, as follows:                1. “closed”—Default enumeration indicating that a message bit stream is to match the definition of the message in the logical model exactly (as implicitly defined in the XML Schema recommendation);        2. “openDefined”—indicates that a message bit stream can contain any elements which have been defined in the current message set; and        3. “open”—the message bit stream can contain any elements, even those that have been defined in different message sets or not defined in any message set. For clarity, the term “message set” is described in co-pending U.S. patent application Ser. No. 10/703,037, incorporated by reference above.        
Another benefit of the message model described above is that it can be used to define physical, wire format specific rendering options. For example, the XMLInclusionRep construct can be used to specify the manner in which a logical XML schema element (either a local element or referenced global element) should be rendered when transmitted in a particular wire format (e.g., render element X as an attribute in messages of wire format Y). Using this construct it is possible to specify that the same logical XML schema element should be rendered differently for each of a number of wire formats.
In a network of systems executing the same message broker software, instance documents containing such logical model extensions and/or such wire format specific rendering options can be exchanged and validated without difficulty, since the message models used to create messages are commonly understood. However, in a heterogeneous environment, some business enterprises may not be executing the same message broker software as a partner defining the non-standard constructs. Such business enterprises will be unable to validate messages sent by its partner as the non-standard constructs will not be understood.
What is needed is a solution which addresses at least some of the above noted difficulties.